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SYSTEMS AND METHODS FOR 
AUTOMATED TRANSACTIONS PROCESSING 

BACKGROUND 

p 

Field of the Invention 

[0001] The present invention relates to systems and methods for automated transactions 

i 

processing. More particularly, the present invention relates to automated systems and 
methods for receiving orders and processing payments, while maintaining accounting of 
individual accounts. 

i 

Background of the Invention 
[0002] Filing customer orders, invoicing customer bills, and processing customer 

payments are among the most common business processes. Yet these simple interactions 

i 

continue to be the source of errors and inefficiencies and customer dissatisfaction. Thus, 
there remains a need to improve the accuracy and efficiency of transaction processing 
and improve customer-to-business communication, decrease costs, and minimize errors. 
Finding a suitable transaction processing approach depends to a very large extent on the 
nature of the customer business interaction. 

« 

[0003] A common business that handles a large number of customer requests is the 

insurance industry. Such businesses receive a large number of customer requests and 
therefore must handle a large number of transactions swiftly and efficiently. However, 
much error occurs in the interaction between a customer's claim for an incident and the 
insurance company's ultimate payment to settle the claim. Much overhead is required for 
the insurance company to handle each claim individually with persons that scrutinize the 
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customer's claim for accuracy and reliability. Thus, insurance companies incur high 

■ 

* 

costs related to the costs of overhead when each customer claim must be individually 
considered by a representative of the insurance company before any payment is made to 
the customer. 

[0004] In a similar manner, a reinsurance company may have to consider a large number 

of claims by insurance companies relating to various contracts that the insurance 
company has with the reinsurance company as well as keeping track of premium 
payments owed by each insurance company. Although the reinsurance company-to- 
insurance company interaction is based on trust, it is often labor intensive because of the 
premium and claim handling. In contrast, the customer-to-insurance company interaction 
is not as manually intensive because at least the premium amounts are fixed and invoices 
can be sent automatically. 

[0005] For example, when an insurance company presents a claim to the reinsurance 

company, the latter routinely prepares a payment to settle the claim, often without 
conducting the arduous tasks of considering the details of validity and reliability of the 
claim. The reinsurance company thereby "trusts" that the insurance company has 
presented a claim that conforms to the agreement between the two companies and does 
not unfairly or unreasonably affects the reinsurance company. Furthermore, any such 
payment to settle the insurance company's claim is typically delayed by the usual delays 
associated with the handling of the claim and preparation and transfer of the payment. 
Similarly, "trust" issues exist for handling premium payments from insurance companies 
to the reinsurance company. 

2 
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Finally, the reinsurance company typically does not conduct a proper accounting 
of the claim(s) that the insurance company(ies) has presented in the sense that generally 
there is no allocation of payments, claims, or premiums to individual contracts, but rather 
only at the customer (insurance company) level. Thus, there is little assurance, other than 
a reliance on the insurance company, that a claim is within the metes and bounds of the 

i 

contract between the two businesses, and that the policy limit has not been exceeded. 
Thus, there are inefficiencies within the reinsurance company's routine of 

handling transactions witl^ its customer and insurance companies. Such inefficiencies 

i 

potentially lead to lost revenue and inaccurate or delayed accounting. 

. / . . 

SUMMARY OF THE INVENTION 

i 

The present invention, as described in the exemplary embodiments presented 
herein, addresses the shortcomings of the efficiencies and inaccuracies that typically 
occur between two or more parties to a business transaction. Such parties may include 
individuals, businesses, agencies, or governments. The examples presented throughout 

< 

this disclosure are directed to interactions between a reinsurance company and its 

i 

customer, an insurance company. However, this example is merely presented for 
simplicity and is not intended to be limiting to the present invention. 

In one exemplary embodiment of the present invention, a system is disclosed for 
transacting business between a customer and a business. The system includes a server 
used by the business and being accessible by the customer, and a customer account 
hosted on the server. The customer account includes automated instructions that allow 
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the customer to direct the business to make an upcoming payment for an upcoming event, 
to request a payment from the business from a previous event, or to pair a payment with 
one or more upcoming events. 

In another exemplary embodiment of the present invention, a system is disclosed 
for transacting business between a customer and a business. The system includes a server 
used by the business and being accessible by the customer, and a customer account 
hosted on the server. The customer account includes means for instructing the business 
to make an upcoming payment for an upcoming event, to request a payment from the 
business from a previous event, or to pair a payment with one or more upcoming events. 

In yet another exemplary embodiment of the present invention, a method is 
disclosed for transacting business between a customer and a business. The method 
includes accessing a customer account on a server used by the business, and instructing 
the business to make an upcoming payment for an upcoming event, to request a payment 
from the business from a previous event, or to pair a payment with one or more upcoming 
events. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIGURE 1 shows an overview of an exemplary process of an embodiment of the 
invention for receiving claims and distributing funds within a reinsurance business. 

FIGURE 2 is a schematic diagram showing an exemplary system of the invention. 

FIGURE 3 is a screenshot showing a model current account summary according 
to an embodiment of the present invention. 
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FIGURE 4 is a block diagram showing an exemplary embodiment of the present 
invention that shows a sequence of events that enables a customer to receive automated 
payments and account information when interacting with a reinsurance company. 

■ 

FIGURES 5-36 are exemplary screenshots that can be used in the exemplary 
processes and systems described in Figures 1-4 above. 

i 

FIGURE 37 shows an exemplary process through which a customer makes a 
payment advice to a business. / 

FIGURE 38 showp an exemplary process through which a customer makes a 
pairing advice to a business. 

FIGURE 39 shows an exemplary process through which a customer makes a 
payment request to a business. 

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 

Exemplary systems and methods according to the present invention utilize a 
universal interface between a customer and a business to facilitate transactions between 
the customer and the business. The exemplary systems and methods presented herein 
decrease the time and labor associated with conventional claims-processing routines, 
resulting in decreased costs and increased efficiency in transactions between the parties. 
Although the exemplary embodiments described herein are made with reference to the 
reinsurance industry as an example, the invention is not limited to this type of business. 
Other types of businesses can benefit from the exemplary systems and methods described 
herein. For example, insurance corporations, government agencies, and other entities that 
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distribute funds or licenses, or other similar businesses or organizations may benefit from 

4 

the systems and methods described herein, with expected modifications, apparent to one 
having skill in the art, to conform to the specific organization. 

[0021] As described above, the reinsurance industry, for example, is characterized by a 

' relatively high level of trust between the reinsurers and their customers (insurance 
companies). In addition, there are typically a large volume of transactions between each 
customer and the reinsurer, i.e., one-time customers are rare. These characteristics of the 
reinsurance business create opportunities for improvement in transaction processing. 

[0022] Because of the relatively high level of trust between the reinsurers and their 

customers (insurance companies), it is practical to allow customers access to internal 
account records. In this way, customers can review records and provide input (e.g., 
payment advice or requests for payment) to improve accuracy and efficiency. Of course, 
there must be a user interface that facilitates such customer interaction. In addition, 
because there are typically a large volume of transactions between each customer and the 
reinsurer, it is possible to improve transaction processing by pairing and offsetting debits 
and credits. 

[0023] In the insurance-reinsurance context, a process for receiving and handling 

customer claims is shown in Figure 1 . System 1 00 includes a front office portion 1 1 1 
and a back office portion 1 12. Although the front office portion 1 1 1 and back office 
portion 1 12 are shown having certain functions, such functions may be shifted 
accordingly such that each office portion 111 or 1 1 2 may have more or fewer functions 
than is shown in Figure 1 . 

6 
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[0024] Front office portion 1 1 1 is primarily involved in the .function of placement 1 30. 

Generally, placement 130 involves negotiation between a customer (e.g., an insurance 
company) and a business (e.g., a reinsurer) to distribute risk. The end result of the 
negotiation is typically a contract or treaty or modification to an existing contract or 
treaty. Several bundles of contracts 1 3 1 and 1 33 are obtained in this front office portion 

1 1 1 function. Each of the bundles of contracts 1 3 1 and 133 may share one or more 

■ 

i 

characteristics. Such acceptances 131 and 133 may include, for example, policies of the 

same line of business, cuirency, types of reinsurance, reinsured or the like. Each bundle 

i 

may include as few as a single contract and as many as several 1000 contracts. Other 
types or organizations o/ the bundles are also possible. 
[0025] After the placement 130, the process proceeds to a series of back office portion 

112 functions, including a technical accounting component 140 and a financial 
accounting component 150. In the technical accounting component 140, the acceptances 

» 

, i 

i 

131 and 133 lead to two claims bordereaux 141 and 143, and premiums bordereaux 142 

A 

and 144, respectively. Generally, bordereaux are lists of all premiums or claims 

1 

movements during a certain accounting period for a specified bundle of contracts. The 

* 

i * 

i ■ 

totals are posted in the financial accounting component 150, which also includes current 
account. All detailed movements are posted in the technical accounting component 140. 

The two Bordereaux then become the basis for one statement of accounts 151 or 
153, respectively, per agreed accounting period. Such period could be, for example, 
monthly, quarterly, or other determinable time period. The one or more statement of 
accounts 151 and 153 then lead to a financial accounting 150 function, which includes 
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current account. Current account allows a customer to perform one or more financial 
transactions such as, for example, a payment request 161, a payment advice 162, or a 
pairing advice 163. Each of these transactions will be described in more detail below. 
Other financial transactions are also possible. In addition, from current account, it is 
1 possible to view a payment request already submitted, to view and/or to delete a payment 
advice, to view payment, and to view pairing information. 

[0026] Referring to the functional aspects of the system and method shown in Figure 1, 

the current account or financial accounting 150 functionality is the last step in the 
reinsurance value chain that is visible to a customer. Furthermore, typically one current 
account exists per customer and contains all the balances of technical reinsurance 
bookings (e.g., statements of accounts 151 or 153), cash call related bookings, payment 
bookings and information about matching/pairing status. A cash call is an advance 
payment the insurance company may request from the reinsurer in case of a large claim 
settlement. The amount will be debited in the next regular statement of accounts. 

[0027] Figure 2 is a schematic diagram showing an exemplary system of the invention. 

System 200 of the invention includes server 240 and account processing engine 250. 
Server 240 can include one server or a network of servers. Server 240 is associated with 
business 230. For example, server 240 can be owned, operated, or otherwise maintained 
by or on behalf of business 230. Server 240 is associated with account processing engine 
250. Account processing engine 250 is associated with a processor that is configured to 
execute processes and methods in accordance with the present invention as described 

8 
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herein. For example, application processing engine 250 may execute various processes 
called for by current account. 
[0028] Server 240 is accessible to one or more customers 210 over network 220. 

» 

Firewall 242 of server 240 is provided to prevent unauthorized access to server 240. The 

use of firewall 242 is well known in the art and it is therefore not described in detail 

i ■ 

herein. 

i 

[0029] Customer 210 and business 230 can communicate with each other via network 

l ■ . ' 

220. Network 220 can b^ any known communications network. Preferably, network 220 

i 

is the Internet. In the context of the reinsurance industry, customer 210 is an insurance 
company that sells insurance policies to insured parties. Business 230 is a reinsurer that 
deals with customer 210 in provision of reinsurance services associated with the 
insurance policies of customer 210. 

[0030] For example, when customer 210 (e.g. , an insurance company) provides business 

i ■ 

c 

230 with a payment advice that includes input data, the input data flows through 
application modules associated with server 240. For convenience, the process associated 
with the applications modules is hereinafter referred to as the "current account" process. 

* • 

[0031] The request is first validated technically to ensure that the input data provided by 

customer 210 fits the minimum data quality requirements. The data quality requirements 
can include, for example, correct syntax, each value of the input data is within a 

■ 

predefined (context-less) range, basic relationships between values in the request are 
correct (e.g., DATE1 is before DATE2), and so on. 
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[0032] Next, modules/functions associated with server 240 can concentrate on business 

i 

validation rules for several processes within current account. For example, the processes 
may include payment advice, payment request, pairing advice. The business validation 
rules can restrict a customer's freedom towards a desired data range and helps to 
' standardize the processes. Filter rules or "business checks" may also be provided to 
determine afterwards whether manual intervention by the business is needed. 

[0033] The systems and methods of the present invention are designed to be user-friendly 

and readily accessible to a customer with minimal manual intervention by a business 
utilizing such systems and/or methods. Thus, a non-limiting means of providing access 
to the systems and/or methods of the present invention is through the Internet. A 
customer may readily access the customer's account through the Internet at any time and 
from any place in the world that allows Internet access. Such access may either be 
provided through hardwire means or remotely. This increased flexibility and lack of 
restraint with respect to time and place for account access provides a tremendous benefit 
to the customer. Likewise, such flexibility offered to the customer provides the business 
with an increased customer base of those who are attracted to such flexibility. 

[0034] A customer may access a system according to the present invention by, for 

example, typing a specific Internet address that enables access to the customer's account. 
Typically, a login page may be used to ensure secured access to the customer account, 
and to prevent unauthorized or fraudulent use of the customer account. Once a customer 
logs into the customer account properly, a menu-drive homepage may be provided, with 
various option pages, such as that shown as exemplary screenshot 300 in Figure 3. 

10 
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Although screenshot 300 is shown having particular features and traits, other screenshots, 
such as screenshot 500 shown in Figure 5 and screenshot 600 shown in Figure 6 are 
within the purview and scope of the present invention, which is not limited to the 

■ 

screenshot shown in Figure 3. 
[0035] Exemplary screenshot 300 is shown having a number of menu items 3 1 0. 

i i 

Each menu item contains a separate screen of features and options for the customer. The 

i 

exemplary menu item shown in Figure 3 is current account 313. Other menu options 

I ' ' ' ' • 

include, but are not limited to, contracts 311, placements 312, user administration 314, 

i 

address book 315, and statistics 3 1 6. Contracts 3 1 1 is intended for viewing details of 
bound contracts and accessing the premiums/claims bordereaux. Placement 3 12 is the 
negotiation area where insurance and reinsurance company submit offers, counter-offers, 
and accept or decline. In user administration 314, the insurance company can administer 
its customer account (i.e., users passwords, users access rights, company address, and 
company bank accounts). Address book 315 may be used for registering email accounts 
of other (competing) reinsurers should the client wish to forward offers to other 
reinsurance companies as well. In statistics 316 the insurance company may generate and 
view online reports on its book of business and its transactions with the reinsurer. The 
current account 3 13 is shown in Figure 3 as an example and is not intended to be limiting 
of the invention or the types of screenshots that are available. 

» 

[0036] Within the current account 313 shown in Figure 3, a number of further options are 

provided to the customer that facilitate the customer's access and functional capacities. 
Header section 320 provides readily accessible parameters that the customer may change 

11 
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to access part or all of the customer account. Some of the options that may be changed in 
the header section include, but are not limited to, entry dates for analysis, transaction 
currency, and status of various account postings. Header section 320 can also filter the 
current account by group company information, posting date, status of booking, and 
' currency. Other options, such as, filtering by reinsurer if more than one reinsurer is 
associated with the application, are possible. 

[0037] Other sections of the screenshot 300 of current account 3 13 are optionally 

available depending on the particular customer account and whether there are applicable 
items within each section. For example, upper section 330 may include, but is not limited 
to, particular items that have been entered into the system by the customer. Such items 
could include matter descriptions, relevant dates, and value amounts. Upper section 330 
farther contains all of the selected bookings. These bookings could include, but are not 
limited to, balances of confirmed statement of accounts 151 or 153 and their 
rectifications, payments (in or out) and cash call requests/regulations. The total of all 
bookings may be shown on the line "Balance Due," which is either a credit (in favor of 
the reinsurance company) or a debit (in favor of the customer). A detailed view may also 
be presented via a hyperlink, by pointing and clicking on the text of the bookings. 

[0038] Middle section 340 contains payments in transit or in the approval process. The 

sum of these bookings and the Balance Due form the Balance Preview. 

[0039] Lower section 350 includes matters that are to be considered to be due or payable 

■ 

in the near future. Such "future due" bookings are pro memoria (e.g., cash call contra 
entries). 

12 
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[0040] Finally, a footer section 360 includes a button option set that allows a 

customer to trigger a financial transaction. Such functional keys enable the customer to 
request specific functions from the system that are processed automatically without 

* 

manual intervention. Such functions include, but are not limited to, payment advice 362, 
payment request 364 or pairing advice 363, as will be described in more detail below. 

* i 

Other optional functions are possible, such as, for example, the customer doing an online 

reconciliation of his current account with the displayed postings, storing comments to 

( •. ( / ■ , . 

♦ i 

individual postings, and scheduling alarms for future actions. 

i 

[0041] Systems and processes according to the present invention automate accounting 

processes that have typically required time-consuming and inefficient manual handling. 
Further, they also improve efficiencies in other transaction areas. Such other, areas 
include, but are not limited to, data exchange between customer and company (e.g., 
reinsurer), validation and plausibility checks, confirmation about the status of a 

■i 

transaction and changes of status. Other areas may also receive benefits from the current 
invention. 

[0042] Access to a customer's current account offers several kinds of functionality 

including, but not limited to, the ability of the customer to view and filter online 
(anytime, anywhere) all of the bookings in the system. The customer also has the ability 
to interact and trigger a financial transaction, depending on the credit/debit balance 
position. Access allows the customer full transparency of postings and enables him to 
reconcile his own accounts without involving personnel of the business. Other 
functionalities are also apparent to one having ordinary skill in the art. 

13 
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Figure 4 shows an exemplary map 400 relating to the viewing and transaction 
processes. Map 400 is merely an example of the viewing and transaction procedures, and 
the current invention is not limited to this specific example. Other examples and 
procedures serving a similar, function and having similar capabilities are within the 
purview and scope of the present invention. Map 400 includes several vertical columns 

i ■ 

that describe some of the functionalities of the exemplary system shown and several 

* * i 

i 

horizontal rows that describe data at various stages through the system. 

A customer may interact with information ori the businesses servers by logging 

i 

into the system interface 401 . The system interface may be via a web page maintained by 
the business on the Internet. The business may provide secure access by requiring a 
customer to login to the system using, for example, a user name and password. 

A customer may view bookings at any time while accessing the system online. 
Such viewing may be in general by viewing all available bookings and balances, or more 
specific by viewing each individual booking detail by hyperlink. Figures 5 and 6 show 
screenshots 500 and 600 respectively. Figure 5 is an exemplary screenshot 500 of current 
account showing all bookings and balances for the specified period of time. This period 
of time does not have to extend through the present so the customer can see the status of 
his accounts for any period of time available. Figure 6 is an exemplary screenshot 600 of 
current account where the screen has been filtered to show an opening balance as of a 
specified date and all remaining balances. 

When a customer chooses the advise payment option (e.g., selects advise payment 
362 from screenshot 300) when viewing the current account 402, shown in Figure 4, the 

14 
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system proceeds to the advise payment column 420, wherein the customer advises the 
business of an upcoming payment which can be paired with one or previous events. The 
customer does not need to pair the upcoming payment with any previous events. At the 
data entry portion 450 of the advise payment option, payment advice portion 421 is 
initiated. At this stage, the system presents a list of all open (e.g., unsettled) current 
account bookings as seen in the exemplary screenshot 700 of Figure 7. The customer 
then selects the open items the customer would like to settle by submitting payment. In 
the exemplary screenshot 700, the customer has selected open items with a $500 credit 
and an $ 1 1 ,000 credit for a total balance of $ 1 1 ,500. 

[0047] The system verifies that the sum of all selected postings is in the system's favor 

and that the advised value date lies within a predefined limit before continuing. For 
example, as seen in screenshot 800 of Figure 8, the customer has selected two open items, 
a $500 credit and a $1000 debit for a total balance of a $500 debit, which is not in the 
systems favor. When such a situation occurs, the system suggests submitting a payment 
request or changing the selections. If, however, the amount is in. the system's favor, then 
the customer is asked to input an expected value date. For example, as seen in screenshot 
900, the customer has entered an expected value date of August 27, 2001 . In the ideal 
scenario (i.e., the total favors the business) the total is a credit and the system proceeds to 
calculate payment advice process 423 in the data submission screen portion 460. 

[0048] When the system proceeds to calculate payment advice process 423, the system 

presents the preferred business bank account depending on, for example, payment 
currency and the customer's country. Furthermore, a unique reference number is 

15 



I J. 

t • 

PATENT SRE0005-US 

t 

generated that the customer is asked to quote in the payment order. Figure 1 0 is a 
screenshot 1000 displaying the expected value date, bank account number, and unique 
reference number. This reference number is later used to recognize the actual payment 
and to pair it in an automated fashion with the technical bookings. The customer then 

♦ 

submits the payment advise information by clicking on the submit payment advice 

j 

button. If there is only a relatively small amount of money due (e.g. , below a 
predetermined amount), the customer may choose a set-off without payment. 

[0049] Figure 1 1 is a screenshot 1 100 showing the option of setting-off without payment. 

i 

In this exemplary scenario, there is a total payment of $1 .00. In order to 1 minimize cost a 
business may offer to set-off without payment (i.e. , forego payment). A business may set 
this amount to any particular amount, such as, for example $20.00. The customer can 
always elect to make the payment; therefore, screenshot 1 100 provides the same 
information regarding expected value date, bank account number, and unique reference 
number. 

[0050] If the total amount equals zero, then the business may offer to match the selected 

debit and credit items. Figure 12 shows screenshot 1200 where the total payment is zero. 

* > 

In this situation, the submit payment advice button is not available because there is no 
physical payment or bank routing necessary. Therefore, in the exemplary screenshot, the 
customer may be directed to select the set-off without payment button as a sign of 
acceptance. 

[0051] If the submission from calculate payment advice process 423 is proper, the system 

proceeds to payment advice confirmation process 425 in the confirmation screens portion 

16 
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470. Here, the customer receives a message confirming the successful booking of the 
payment advice or set-off request. Exemplary screenshot 1300 shown in Figure 13 is an 
example confirming the successful booking of the payment advice, while exemplary 
screenshot 1400 shown in Figure 14 is an example confirming the set-off without 
' payment. Once the payment advice confirmation process 425 is complete and the 
customer has acknowledged it, the system returns to the current account 402. After 
returning to the current account 402, the customer may automatically ascertain the effects 
of the just-implemented payment advise. 

[0052] If, however, an error occurs due to technical problems while trying to complete 

the calculate payment advice process 423, the system proceeds to the failed transaction 
confirmation process 480. Exemplary screenshot 1500 shown in Figure 15 advises the 
customer that the transaction has failed and request the customer to try again later. If the 
problem continues to occur the customer is encouraged to contact the business. After the 
customer acknowledges this screen, the system returns to current account 402 where the 
customer may perform any other tasks. 

[0053] When a customer chooses the request payment option (e.g., selects request 

payment 364 from screenshot 300) under the current account 402, the system proceeds to 
the request payment column 430, wherein the customer requests a payment from the 
business for a previous event. At the data entry portion 450 of the request payment 
option, payment advice process 431 is initiated. The business presents a list of all open 
(e.g., unsettled) current account bookings to the customer as seen in the exemplary 
screenshot 1600 of Figure 16. The customer selects which of the open items are to be 

17 
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settled by requesting a payment from the business. In screenshot 1600, the customer has 
selected open items with a $500 debit, an $1 1,000 debit, and a $1000.00 credit for a total 
balance of $10,500. 

[0054] The system then verifies that the sum of all selected postings is in the customer's 

favor before continuing. For example, as seen in screenshot 1700 of Figure 17, the 

i 

customer has selected only a $ 1 000 credit and no debit amount. Another example shown 

i * 

i 

in screenshot 1800,of Figure 18,ia $1000 credit and a $500 debit for a total balance of a 
$500 credit, which is not jn the customer's favor. When such a situation occurs, the 
system suggests submitting a payment advice or changing the selections.' Yet another 
example shown in screenshot 1900, another error has occurred. In the ideal scenario (i.e., 
the total favors the customer) the total is a debit and the system proceeds to calculate 

* 

payment request process 433 in the submission screen portion 460. 
[0055] When the system continues to the calculate payment request process 433, the 

business lists some or all of the customer's bank accounts in payment currency as known 

* - * 

by the business. The customer then selects the bank account to which the payment 
should be remitted. Furthermore, the customer can enter a reference text for easy 

i 

* i 

V 

recognition by the customer once the money has been transferred to the customer's 
designated destination. Figure 20 is an exemplary screenshot 2000 displaying list of 
customer's bank accounts, place for the customer to enter the reference text, and several 
buttons. From this screen the customer can choose to submit payment request or to set- 
off without payment. If there is only a relatively small amount (e.g., less than a 
predetermined amount) that the business owes the customer, the customer may be asked 
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to agree to a set-off without payment (i.e., forego payment). The system then verifies 

i 

i 

that all data entry has been entered correctly, and then proceeds to the next process. 
[0056] If the submission from calculate payment request process 433 is proper, the 

system proceeds to payment request confirmation process 435 in the confirmation screens 
1 portion 470. Here, the customer receives a message confirming the successful booking of 
the payment request or set-off request. Exemplary screenshot 2100 shown in Figure 21 is 
an example confirming the successful booking of the payment request, while exemplary 
screenshot 2200 shown in Figure 22 is an example confirming the set-off without 
payment. Once the payment request confirmation process 435 is complete and the 
customer has acknowledged it, the system returns to the current account 402. After 
returning to the current account 402, the customer may automatically ascertain the effects 
of the just-implemented payment request. The payment request may then be further 
reviewed by one or more authorized parties (e.g., accountants of the business) before the 
actual payment is authorized. Such payment may be processed through, for example, 
payment order to a local operational data store, and from there via an electronic network 
to the customer's bank. 

[0057] If, however, an error occurs due to technical problems while trying to complete 

the calculate payment request process 433, the system proceeds to the failed transaction 
confirmation 480 process and screenshot 1500, as shown in Figure 15, will be displayed. 

[0058] If the customer chooses the pairing advice option (e.g. , selects pairing advice 363 

■ 

from screenshot 300) when viewing current account 402, shown in Figure 4, the system 
proceeds to the pairing advice column 440, wherein the customer allocates specific 

* 
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payment(s) with specific technical bookings. At the data entry portion 450 of the pairing 
advice option, the pairing advice process 441 is initiated. The customer is requested to 
present pairing advice - technical bookings information. If the business is unable to pair 
a customer's payment to open current account bookings (e.g., due to non-use of payment 
advice functionality), the customer can do so manually using the pairing advice process. 

* 

One or more lists of information may be presented to the customer, such lists including, 

^ 

i 

i 

but not limited to, unpaired payment bookings, unsettled (e.g., due or overdue) technical 

♦ , 

current account bookings (e.g., mainly statements of accounts), or the like, as seen in 

i 

exemplary screenshot 2300 of Figure 23. Other types of information may also be 
presented as lists. The customer then selects which of the open items shall be paired with 
particular payment(s) by allocating among the open items the ones that are to.be matched. 
The system then first verifies that the sum of all selected technical postings plus an 
acceptable set-off amount is less than or equal to the total of unpaired payment bookings 

■ < 

before proceeding. 

[0059] If the system proceeds to the calculate pairing advice process 442 within the data 

entry screen portion 450, information relating to the pairing advice - payment bookings is 

i * 

i 1 

requested. The system presents several lists including, but not limited to, technical 
current account bookings as selected (e.g., on previous screen) by the customer for 
matching, all unpaired payments contained in the current account, or the like, as seen in 

■ 

exemplary screenshot 2400 of Figure 24. Other lists are also possible. Furthermore, the 
system proposes how to pair or allocate the open payment bookings using, for example, a 
first-in first-out principle. In the exemplary screenshot 2400, the system has proposed 
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matching a $350 debit and a $3 1 0 debit with a $500 credit. The customer may then 
instruct which and how much of the open payments shall be paired, either fully or 
partially. The system may be configured to allow only one partial selection. The system 
may then verify the input. In case of a small (e.g. , predetermined amount) discrepancy 
between technical and payment bookings, the system proposes a write-off of the pairing 
difference, either by the business or the customer. Exemplary screenshot 2500 of Figure 
25 shows a scenario where the business is willing to write off the pairing difference 
amount. 

.'nli*M t 

If the customer selects only full payments and there is a small discrepancy 
between the technical and payment bookings the system may present the customer with 
either exemplary screenshot 2600 of Figure 26 or exemplary screenshot 2700 of Figure 
i7. More specifically, screenshot 2600 shows the scenario where the business is willing 
to write off the difference because the checked full payments is slightly smaller than the 

4 

total of the open item. Screenshot 2700 shows the scenario where the business asks the 
customer if he is willing to write off the difference because the checked full payments is 
slightly greater than the total of the open item. If the customer is not willing to accept the 
set-off the customer can go back and make different selections. 

If the submission from calculate pairing advice process 442 is proper, the system 
proceeds to pairing advice submission process 443 in the submission screen portion 460. 
In this process, the business presents the customer with the result of the previous two 
processes for review. Exemplary screenshot 2800 of Figure 28 shows a screen 
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t 

summarizing the proposed pairing. The customer can then conduct a final verification of 
the information before submitting the data. 

If the data is submitted, the system processes the pairing advice and returns to 

» 

current account 402 and has immediate access to the results of the just-performed pairing 
instructions. If there are any processing errors (e.g., technical), the system proceeds to 
the failed transaction confirmation process 480 and screenshot 1500, as shown in Figure 

■ 

15, will be displayed. 

i ; . 

In addition to advjsing of a payment, requesting a payment, or making a payment 
from current account, it is possible to see details of existing payment advice, payment 
request, or pairing by selecting it from the screen. For example, a customer on screenshot 
300 could select "Your Payment Advice" to review the details about the payment advice. 

When a customer chooses to view a payment request (e.g. , selecting the existing 
payment request) when viewing the current account 402, shown in Figure 4, the system 

, » 

■i 

proceeds to the view payment request process 491 in the current account transaction 

4 

details portion 490. The customer is presented with details of the payment request. 
Exemplary screenshot 2900 of Figure 29 shows information about the payment request. 

* 

r 

In this exemplary embodiment, no further action is possible from this screen accept to 
return to current account. 

When a customer chooses to view a payment advice (e.g., selecting the existing 

* 

payment advice) when viewing the current account 402, shown in Figure 4, the system 
proceeds to the view payment advice process 493 in the current account transaction 
details portion 490. The customer is presented with details of the payment advice along 
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with the option of deleting the payment advice. Exemplary screenshot 3000 shows 
information about the payment advice. In this exemplary embodiment, the customer has 
an option to delete the payment advice. If the customer chooses to delete the payment 
advice, the system may first request confirmation as seen in screenshot 3 1 00 of Figure 
31. 

i 

[0066] If the customer confirms the deletion of the payment advice, the system proceeds 

to delete payment advice process 495 in the current account transaction details portion 
490. The system deletes the payment advice and presents confirmation that the payment ' 
was deleted. Exemplary screenshot 3200 of Figure 32 advises the customer that the 
payment advice was deleted. 

i 

[0067] When a customer chooses to view pairing information while viewing the current 

account 402, shown in Figure 4, the system proceeds to the view pairing information 
process 499 in the current account transaction details portion 490. The customer is 
presented with details of a pairing in screen shot 3500 of Fig. 35. The screen shot 3500 
may display details about the pairing process and the customer can view details from the 
respective statement of accounts by clicking on one of the paired items. Screen shot 3600 
of Fig. 36 shows rectification information as well where two statements of accounts have 
been rectified. If the pairing resulted in a partial pairing, the information is split into a 
"paired" portion and an "unpaired portion." 

[0068] When a customer chooses to view a payment when viewing the current account 

402, shown in Figure 4, the system proceeds to the view payment process 497 in the 
current account transaction details portion 490. The customer is presented with details of 
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either an incoming payment made by the customer in favor of the reinsurer, as seen in 
screen shot 3300 of Fig. 33, or an outgoing payment from the reinusurer in the favor of 
the customer, as seen in screen shot 3400 of Fig. 34. The payment screen can show the 
rate of exchange for the incoming or outgoing payment. If the payment is partially paired 
as shown in screen shot 3300, the customer is given an opportunity to viewing the pairing 
by clicking on the according button. 

' * i 

i 

The current account system and processes described above can be used in a back 
office context. 

i 

In the back office context, Figure 37 shows an exemplary process 3700 through 
which a payment advice may be processed by the business in a preparation-negotiation- 
performance-acceptance (PNPA) model. 

Once a customer has accessed current account through the business supported 
interface and selected advise payment, the system proceeds to the "Preparation" portion 

•i 

of the PNPA model. The system obtains the information provided by the customer 

• * 

regarding amount, expected value date, and which items to pay or set-off at "D: Register 
Payment Advice." The system validates the payment advice at "V: Validate payment 

j 

advice" and if it is validated, the system seeks web confirmation at "C: Confirm 
Payment/Set-off advice." If not, the system indicates to the customer the nature of the 
error and await correction. Once the customer confirms the payment of set-off, the 
system proceed to either "P: Package Information-Pay Adv." or "P: Package Information 
- Set off accordingly. The "P: Package Information-Pay Adv." contains information, 
such as, advised items, value date, total amount, reference number, and business bank 
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account details. The "P: Package Information - Set off includes information, such as, 
advised items and write off amount (if any). 

During the "Negotiation" portion of the PNPA model, the system receives the 
package information at either "D: Get packaged information-Pay Adv." or "D: Get 
packaged information - Set off." The information may optionally go through several 
checks at "F: Business check Payment Advice." or "F: Business check Set off." Checks 
for payment advice may include late payments for minimum deposits. Checks for set-off 
may include determining that the customer is not bankrupt. These checks are merely 
exemplary and if no checks are provided the system passes the information to the 
"Performance" portion of the PNPA model. 

At "Performance" the system either passes to "A; Make booking (Payment)" or 
'''A: Make booking (Set off)." "A: Make booking (Payment)" causes the system to post a 
preliminary entry to current account and change the status of the selected open items to 
"payment in transit." "A: Make booking (Set-off)" causes. the system to post DIFF 
booking and matching payments. 

If the payment advice resulted in payment, the system indicates payment advice 
processed. If the payment advice resulted in a set-off, the system proceeds to "A: Export 
Pairing Information to LODS." From there the system indicates Set-Off advice 
processed. 

In the back office context, Figure 38 shows an exemplary process 3800 through 
which a payment request may be processed by the business in a PNPA model. 
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[0076] Once a customer has accessed current account through the business supported 

interface and selected payment request, the system proceeds to the "Preparation" portion 
of the PNPA model. The system obtains from the client the bookings in favor to client 

» 

and may also include bookings in favor to the business if they are overdue, amount, 
currency, statement of account reference, clients bank account, and a unique identifier if 
entered by the client at "D: Request Payment." The system validates the payment request 
at "V: Validate Payment Request" and if it is validated, the system proceeds to either "P: 

Package information - Pay Req" or U P: Package Information - Set off accordingly. The 

i 

U P: Package Information - Pay Req." contains information, such as, advised items, total 
amount, reference number, and customer bank account details. The "P: Package 
Information - Set off includes information, such as, advised items and write, off amount 
(if any). 

[0077] During the "Negotiation" portion of the PNPA model, the system receives the 

i 

package information at either "D: Get packaged information-Pay Req." or "D: Get 
packaged information - Set off." The information may optionally go through several 
checks at "F: Business check Payment request." or "F: Business checks - Set off." 
Checks for payment advice may include late payments for minimum deposits. Checks 
for set-off may include determining that the customer is not bankrupt. These checks are 
merely exemplary and if no checks are provided the system passes the information to the 
"Performance" portion of the PNPA model. 
[0078] At "Performance" the system proceeds to either "A: Make preliminary booking 

(pay req)" or "A: Make preliminary booking (set off)." "A: Make preliminary booking 



26 



PATENT SRE0005-US 

< 

(pay req)" causes the system to post a preliminary entry to current account and change 
the status of the selected open items to "payment in transit." It also determines a 
payment due date in the future, for example, three days. "A: Make preliminary booking 
(setoff)" causes the system to make a preliminary booking. 

After making the preliminary booking, the system seeks confirmation from the 
customer at either "C: Confirm Set off request" or U C: Confirm Payment request in the 
"Acceptance" portion of the PNPA model. Once the customer confirms, the system 
indicates either "Payment Set Off processed" or "Payment Request Processed." 

■ '■i(.>y i - • 

In the back office context, Figure 39 shows an exemplary process 3900 through 
which pairing advice may be processed by the business in a PNPA model. 

Once a customer has accessed current account through the business supported 
interface and selected payment advice, the system proceeds to the "Preparation" portion 
of the PNPA model. The system obtains the information provided by the customer 
regarding the selected open or overdue items for pairing at "D: Select open/overdue items 
for pairing." The system validates the pairing at "V: Validate Pairing." If not validated, 
the system returns to "D: Select open/overdue items for pairing." If validated, the system 
requests the customer to allocate unpaired payments, either fully or partially, to the 
open/overdue items selected for pairing at "D: Allocate unpaired payments." The system 
validates the allocation at "V: Validate Allocation." If not validated, the system returns 
to "D: Allocate unpaired payments." If validated, the system proceeds to "P: Package 
information - Pairing." The "P: Package information - Pairing" contains information, 
such as, selected payments and selected open/overdue items. During the "Negotiation" 
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portion of the PNPA model, the system receives the package information at "D: Get 

i 

packaged information - Pairing." The information may optionally go through several 
checks at "F: Business check Pairing Advice." These checks are merely exemplary and if 
no checks are provided the system passws the information to the "Performance" portion 
of the PNPA model. 

At "Performance" the system proceeds to "A: Make booking into current 
account." "A: Make booking (Payment)" causes the system to indicate in current account 

that the payments are paired and the open/overdue items are settled 

■><it*t>i 

After making the booking into current account, the system seeks confirmation 
from the customer at "C: Confirm pairing advice." in the "Acceptance" portion of the 
PNPA model. Once the customer confirms, the system indicates "Pairing advice 
processed." 

Each of Figures 37-39 provide keys indicating the nature of the processing that 
occurs at each step. It is understood that other processing means may be used without 
departing from the scope of the invention. 

The exemplary systems and methods described above according to the present 
invention have many advantages. One such advantage is that the interaction between the 
customer and the business is automated. This automation reduces the costs and errors 
associated with non-automated processes, such as, for example, person-to-person 
communications. Furthermore, all transactions are electronically recorded, thus reducing 
the potential for miscommunication between live parties. Another advantage of this 
system is that a customer's balance can fluctuate day by day. One day the customer may 
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owe the business and the next be entitled to the payment. This system provides full 
transparency for the client because he can see the daily values and use them to reconcile 
his accounts. Through the system described above, a customer can choose when it is best 
to act to make a payment or request payment because he is in full control of his accounts. 
This is beneficial to the business as well because they can rely on the customer's input, 
eliminate the need of manual entry, and minimize the amount of processing when 
payments from the customer are-made or payments to the customer are required. 

[0086] Another unique advantage of the systems and methods according to the present 

i 

invention is their ability for rapid expansion. Although the present invention is presented 
with very specific examples of procedures that are most commonly encountered in the 
reinsurance business, the invention is not restricted to this type of business. Any business 
that could benefit from automating transactional encounters between the business and its 
customers would benefit from the use of this invention. The parameters, options and 
paths shown in the exemplary embodiments of the figures could be programmed to 
account for the specific requirements and unique business options of any other business. 
[0087] In describing representative embodiments of the invention, the specification may 

* * 

have presented the method and/or process of the invention as a particular sequence of 
steps. However, to the extent that the method or process does not rely on the particular 
order of steps set forth herein, the method or process should not be limited to the 
particular sequence of steps described. As one of ordinary skill in the art would 
appreciate, other sequences of steps may be possible. Therefore, the particular order of 
the steps set forth in the specification should not be construed as limitations on the 
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claims. In addition, the claims directed to the method and/or process of the invention 

« 

should not be limited to the performance of their steps in the order written, and one 
skilled in the art can readily appreciate that the sequences may be varied and still remain 
within the spirit and scope of the invention. 

The foregoing disclosure of the embodiments of the invention has been presented 
for purposes of illustration and description. It is not intended to be exhaustive or to limit 
the invention to the precise forms disclosed. Many variations and modifications of the 
embodiments described herein will be apparent to one of ordinary skill in the art in light 
of the above disclosure. The scope of the invention is to be defined only by the claims 
appended hereto, and by their equivalents. 
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